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Summary:  This  paper  is  about  human  factors  integration,  and  providing  information  displays  to  match  the 
operators’  requirements.  It  addresses  Man-Machine  Interfaces  and  visualisation  techniques.  It  will  describe  a 
method  of  requirements  capture  that  translated  into  highly  acceptable  and  very  effective  information  displays. 

Background:  The  main  background  to  this  analysis  methodology  comes  from  two  projects  that  have  been 
conducted  at  DERA  Malvern.  Both  projects  were  about  developing  a decision-support  system.  The  task  for 
which  this  system  was  required  involved  detecting  threats,  identifying  their  nature,  tracking  them  and 
predicting  their  implications  and  the  hazards  they  posed.  The  decision  then  concerned  what  resources  to 
assign  against  the  threat,  and  when.  This  required  information  about  what  resources  were  available  and  against 
what  they  might  be  allocated. 

The  Human  Computer  Interface  (HCI)  implementation  for  one  system  was  strongly  legacy-system  based,  with 
well-established  functionality  that  simply  had  to  be  re-implemented  with  new  technology,  refining  an  existing 
task.  The  other,  new  application  had  a well  defined  purpose,  but  no  functionality  defined  at  the  outset,  and 
required  development  from  nothing. 

The  decision-support  requirement:  Both  of  these  projects  were  essentially  about  providing  decision- 
support.  For  the  newer  Athena  project  this  focused  on  the  weapon  allocator's  role.  The  weapon  allocator's  task 
is  to  decide  what  response  is  required  and  to  select  the  counter-weapons  from  those  available.  The  decision- 
support  system  provides  the  overall  tactical  picture  on  a graphical  map  display,  showing  the  options  and 
intercept  progress  on  an  associated  display.  This  provides  the  necessary  information  to  select  a weapon, 
displays  the  information  reported  back  on  engagement  status,  and  enables  subsequent  shots  to  be  scheduled 
and  taken.  The  interface  provides  the  facility  for  the  allocator  to  transmit  the  weapon-firing  request  to  the 
weapon  controller. 

The  prototyping  philosophy  for  this  project,  exploited  a skeleton  set  of  phases  and  modes  of  command  and 
control  against  which  to  assess  an  offered  solution  for  acceptability. 

The  legacy  system:  This  was  a capability  maintenance  project  for  equipment  that  required  replacement  — 
with  the  emphasis  on  exploiting  commercially  available  technology.  From  a survey  of  what  new  technology 
could  offer,  coupled  with  a review  of  existing  standards,  a set  of  Guidelines  was  produced  for  implementing 
the  replacement  system,  validated  by  prototype  demonstrations  and  implementations  for  operational  service. 

Their  aim  was  to  aid  the  production  of  HCIs  with  effective  handling  and  display  of  computer  generated 
information.  These  included  displays  of  graphical  and  tabular  information,  graded  according  to  urgency, 
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enhanced  by  symbology  and  colour,  and  supplemented  by  other  media.  The  Guidelines  also  contain  further 
information  that  impacts  on  HC1  design,  for  example: 

• operator  role  and  target  audience  descriptions; 

• impact  beyond  the  work-station,  e.g.  the  console  design  or  control  room  layout; 

• particular  implementations  identified  as  generic  components,  e.g.  communications  control  panels;  or 

• particular  implementations  for  specific  operator  roles. 


Two  factors  drove  their  further  development.  Whilst  the  existing  Guidelines,  for  the  most  part,  addressed  a 
specific  problem,  it  was  fortunately  one  that  comprehended  whole  control  rooms.  This  meant  they  could  be 
applied  to  other  systems  as  a default  solution  with  particular  differences  resolved  by  exception.  There  were 
several  such  applications  for  which  the  Guidelines  were  perceived  to  be  relevant.  To  be  able  to  mandate  the 
Guidelines  for  future  procurements,  they  would  have  to  be  interpreted  for  each  new  application.  This  in  turn 
demanded  a requirements  capture  and  HCI  assessment  methodology  to  do  this.  The  “greenfield  site”  Athena 
project  provided  the  basis  for  the  answer. 

The  Athena  (greenfield)  system:  The  Athena  project  began  with  no  such  functionality  constraints.  The 
objective  was  to  build  a Command  and  Control  (C2)  demonstrator  for  a decision-aiding  system  for  anti- 
ballistic  missile  weapon  allocation  and  control.  The  threat  was  well  enough  definable,  but  had  not  been 
translated  into  functional  requirements:  the  tasks  to  support  those  functions  were  completely  undefined.  The 
Athena  HCI  Assessment  Suite  was  evolved  to  provide  the  necessary  requirements  capture  methodology  for 
this  project  and  to  develop  the  highly  useable,  internationally  demonstrated  interfaces.  Subsequently,  the 
opportunity  arose  to  develop  this  requirements-capture  and  HCI-assessment  methodology  and  harness  it  to  the 
Guidelines  for  how  to  use  the  technology  derived  from  the  legacy  system  project,  in  order  to  exploit  the 
synergy  and  produce  a generic  HCI-analysis-and-design  package. 

The  Guidelines  comprise  the  following  components: 

1 . Guidelines  for  the  Guidelines  (why  and  how  they  should  be  used); 

2.  generic  core  guidelines; 

3.  annexes  and  case  studies; 

4.  assessment  methodology. 


It  has  been  said  that  Command  and  Control  is  the  glue  that  holds  a system  together — a system  being  defined 
as  collection  of  separate  components  that  are  connected  together.  These  cover  aspects  of  the  operator  role  (e.g. 
receiving  briefing,  detecting  targets,  prosecuting  targets  and  reviewing  task  success)  that  are  affected  by  the 
system  context  and,  conversely,  aspects  of  how  the  operator  contributes  to  the  specific  functioning  of  the 
equipment  through  the  generic  tasks  of  direction,  control,  monitoring  and  appreciating  the  situation. 

Figure  1 illustrates  some  of  the  component  tasks  required  by  such  operator  roles.  Here,  performance 
information  is  derived  from  performing  the  task  — from  the  attempts  to  perform  the  required  functions.  Not 
all  performance  information  is  relevant.  The  reporting  criteria  represent  the  questions  while  the  reports 
represent  the  assessment  results  about  interference  with  other  ongoing  plans.  These  intentions  may  be 
encapsulated  in  a user  guide,  which  describe  what  the  system  is  supposed  to  do. 
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Figure  1.  Elements  of  command  and  control 


The  point  to  develop  here  is  that  there  are  a number  of  generic  human  contributions  to  a command  and  control 
system  by  which  the  command  node  occupied  by  an  operator  role  may  be  analysed.  These  generic  command 
nodes  or  operator  roles  are: 

• command  (and  planning); 

• communications  (information  exchange  and  status  reporting); 

• navigation  and  piloting; 

• tactical  situational  awareness; 

• system  operation; 

• system  monitoring  (alarms,  alerts  and  warnings); 

• operational  co-ordination. 

These  operator  roles  or  command  nodes  then  become  the  components  that  are  held  together  by  the  command 
and  control  system.  There  is  primary  command  requiring  general  situational  awareness  and  planning  of 
operations.  There  are  communications  with  outside  parties,  both  receiving  information  and  transmitting.  There 
are  surveillance  and  watchkeeping  tasks  with  tactical  situational  awareness.  There  is  the  notion  of  navigating, 
which  may  be  position-plotting,  course  setting  or  directing  the  plan  of  execution.  There  is  system  or 
equipment  operation.  There  is  system  monitoring  with  the  associated  alarms,  warnings  and  alerts.  There  is  the 
need  to  support  internal  co-ordination.  All  of  these  are  aspects  of  the  operator  roles  that  define  the  functional 
requirement  for  the  work  place  and  workstations.  These  must  be  designed  to  accommodate  the  potential 
operators  who  will  perform  their  role  or  roles  there. 

Principal  system  functions 

The  following  are  the  principal  system  functions  for  applications  with  which  a typical  C2  system  must 
integrate,  both  in  terms  of  sources  of  command  and  items  for  control  (see  Steinhausen  et  al,  1978): 

• command  and  communications,  e.g.  radio 

• prime  task  integration,  e.g.  gun,  missile  launchers 

• manoeuvring  and  transportation,  e.g.  tractors  and  trailers 

• environmental  defence,  e.g.  weather  protection 

• common  support,  e.g.  power  supply 

• life  support  and  habitability,  e.g.  clean  air 

• system  monitoring,  maintenance  and  repair,  e.g.  food,  sleep 
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These  are  imbedding  dimensions  that  are  both  mission  and  system  related.  This  is  because  the  system  (and  its 
operator  interactions)  must  be  justified  by  its  mission  purpose  — there  must  be  a reason  for  why  it  is  there. 
Equally,  by  continuing  to  ask  the  question  ‘How?’  — ‘rolling  in’  — the  answers,  which  define  what  the 
system  must  support,  will  fall  naturally  into  these  categories. 

For  instance,  these  principal  system  functions  provide  categories  for  analysing  system  failure  effects  and  their 
impact.  The  design  implications  are  then  to  determine  what  can  be  done  to  defend  against  such  failures  by 
preventive  or  corrective  measures,  and  to  assess  the  importance  of  doing  so.  Thus,  these  “system  functions” 
provide  a basis  for  analysing  the  “total  system”  requirements  for  operator  interactions,  both  in  terms  of  their 
environment  and  the  systems  they  control.  They  can  be  analysed  according  to  how  the  command  and  control 
system  will  orchestrate  the  concerted  operation  of  what  has  to  be  done  (jobs,  tasks  and  functions)  by  their 
constituent  components  (people,  missions  and  technology)  in  order  to  achieve  the  required  purpose  of  the 
whole  organisation. 

The  design  process 

The  philosophy  of  the  system  evolution  process  must  take  into  account  two  components:  the  abstract  and  the 
real  system  implementation.  The  design  process  for  a workstation  or  console  is  naturally  iterative  between 
these  two  aspects,  if  only  because  at  the  outset  the  user  does  not  know  what  is  technically  feasible,  nor  does 
the  technologist  know  what  the  user  might  require  if  he  knew  what  could  be  provided.  As  far  as  a system 
manufacturer  is  concerned,  the  human  contribution  to  its  operation  is  firmly  in  the  abstract  realm  — just  as 
much  as,  say,  integrated-circuit  design  or  software  code  is  beyond  the  real  world  of  those  who  use  the 
equipment.  However,  from  a total  system  perspective,  there  is  some  overlap  between  these  two,  where  the 
human  comes  into  contact  with  the  equipment  - the  so-called  “man/machine  interface”.  On  one  side  of  this 
contact  area,  the  system  must  be  integrated  (the  HCI);  the  human  must  adjust  to  the  situation  (the  Human 
System  Interface  (HSi))  on  the  other.  These  different  interests  and  their  implications  for  integrating  Human 
Factors  into  HCI  design  are  described  elsewhere  (see  Smalley  (1997)). 

At  this  point  it  will  be  helpful  to  distinguish  between  super-systems  that  contain  everything  that  is  subject  to 
design,  and  sub-systems  with  respect  to  the  HCI  system  design.  The  super-system  is  the  context  which  drives 
the  requirement  (and  is  itself  driven  by  its  invariant  hyper-system  — the  system  in  its  most  extended  foim, 
w'hich  provides  the  fixed  context  for  the  whole  system  implementation),  whilst  sub-systems  contain  the  sets  of 
co-ordinated  elements  for  performing  the  tasks.  This  gives  the  following  five-layered  model: 

1.  hyper-system; 

2.  super-system; 

3.  system; 

4.  sub-system; 

5.  component  elements. 

The  hyper  system,  super  system  and  system  levels  relate  to  the  abstracted  environment;  the  system,  sub- 
system and  system  elements  relate  to  the  real  components. 

In  teims  of  implementation,  this  translates  into  three  levels  of  interest,  working  outwards  from  the  technology 
behind  the  hardware  (levels  5,  4 and  3),  to  the  operator  at  the  console  or  workstation  design  (levels  4,  3 and  2) 
and  then  the  operational  context  of  the  user,  which  is  bounded  by  the  control  room  (levies  3,  2 and  1).  The 
prototyping  process  then  allowed  the  system  design  to  be  drawn  out,  using  a skeleton  set  of  task  phases  and 
modes  of  command  and  control  to  draw  out  the  required  system  operations  and  to  assess  the  design  concept 
for  acceptability. 

The  Athena  design  evolution  used  an  iterative  process  of  designing  a little  and  building  a little,  then  running 
an  operator-assessment  trial  to  ensure  that,  with  each  step,  the  evolving  design  remained  on  course  towards 
the  end  design.  Thus  each  instance  provided  the  stimulation  to  determine  the  way  forward  and  take  the  system 
design  from  abstract  concept  to  tangible  execution. 
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Figure  2 depicts  the  iterative  nature  of  the  system  design  process  for  human  interaction  at  any  particular  level 
of  hyper-system  and  sub-system.  Here,  the  console  issues  pivot  between  the  hyper-system  beyond  the  control 
room  and  the  sub-systems  of  console  components  — between  requirements  set  by  the  super-system  and 
specification  of  sub-system  components.  This  describes  five  major  phases  in  this  process:  primary 
requirements  capture  (1-2),  derivation  of  constraints  and  secondary  requirements  (2-3-4  and  8-4),  feasibility 
checking  (4-5),  implications  for  host  organisation  (criteria  of  acceptability:  5-6-7)  and  design  specification  (7- 
8)  leading  to  requirement  definition  for  next  level  of  detail. 
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Figure  2.  Analysis  and  design  iteration 

The  draft  system  requirement  and  criteria  are  determined  at  (1 ).  This  is  the  requirement  identified  at  the  super- 
system level  to  fulfil  the  task,  concentrating  on  the  functional  requirement. 

The  component  functions  (I/O  signals)  are  drafted  at  (2).  This  translates  the  functional  requirement  into  a 
functional  specification  at  the  component  level. 

Derivation  of  constraints  and  requirements:  Model  implications  are  derived  at  (3).  This  prototypes  the 
subsystem  by  whatever  models  or  simulations  are  appropriate  for  the  purpose  of  representing  it  — in  order  to 
produce  the  information  which  will  enable  discrimination  between  alternative  options  for  final 
implementation. 

Feasibility  checking:  The  feasibility  that  the  system  will  work,  as  a function  of  its  component  behaviours,  is 
assessed  at  (4).  This  concerns  whether  the  components  will  live  together  compatibly.  The  check  on  system 
implications  at  (5)  concerns  whether  the  output  of  the  subsystem  is  compatible  with  the  requirement  imposed 
by  the  super-system. 

Implications  for  host  organisation:  ft  is  necessary  to  agree  or  confirm  the  system  interface  at  (6).  Once 
satisfied  that  the  super-system  requirements  can  be  met  by  the  proposed  system  design,  this  is  confirmed,  so 
that  the  super-system  can  be  reconfigured  to  receive  the  new  system  and  its  sub-systems. 

Specify  design:  The  system  design  stage  entails  refining  the  component  options  and  specifying  the  system 
when  down  to  one  option  at  (7).  If  any  options  remain  at  (8),  then  iterate  from  (3)  with  model  implications, 
determining  feasibility,  etc. 

Command  structures  and  decision  nodes 

Since  the  design  process  is  in  itself  a decision  process  analogous  to  command  and  control,  it  should  be 
possible  to  map  across  to  a generic  command  and  control  structure. 
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There  are  two  types  of  command  and  control:  one  has  the  command  structure  embedded  in  the  system 
components,  and  is  therefore  real  to  the  controlled  system.  For  the  other  type,  the  command  system  is  hosted 
by  a separate  entity  (for  example  the  people  in  an  organisation)  from  the  controlled  system  to  which  it  is 
connected  by  formal,  specifiable  and  configurable  links  or  communication  channels,  and  is  therefore 
abstracted  from  the  real  system. 

Figure  3 is  an  information  flow  diagram  that  illustrates  some  important  aspects  of  the  system  of  controlled 
functions  that  link  the  generic  command  nodes  identified  earlier.  This  shows  the  whole  process  running  from 
primary  situational  awareness  at  the  top  left  to  internal  system  co-ordination  at  the  bottom  right. 


Figure  3.  The  C2  modes  for  tactical  decision  making 

The  left  half  of  this  diagram  is  concerned  with  the  driving  influences  of  the  outside  world.  In  the  field,  these 
are  appreciated  by  commanders:  they  are  analysed  to  generate  the  operational  and  functional  requirement  for 
the  system.  The  right  half  is  concerned  with  the  system  under  control  (whether  for  real  or  as  a technical 
specification).  The  upper  half  is  concerned  with  command  and  direction:  the  lower  half  is  concerned  with  the 
execution  and  implementation  of  the  system  puipose.  The  flow  lines  in  this  diagram  represent  or  provide  for 
either  of  two  processes: 

1 . the  thinking  processes  or  modes  of  using  the  information  in  a command  and  control  system; 

2.  the  sequence  for  analysing,  designing  and  implementing  a system. 

These  C2  modes  (as  opposed  to  the  nodes  described  earlier)  are  as  follows. 

1.  Primary  situational  awareness  is  concerned  with  answering  why  is  this  system  here  and  doing  what  it  is 
doing.  It  is  concerned  with  collecting  all  the  information  that  focuses  on  this  answer. 

2.  Planning  is  concerned  with  taking  in  the  current  state  of  the  mission  field  and  determining  what  aims  to 
drive  for.  This  combines  the  why  of  primary  situational  awareness  with  the  where  of  current  situational 
awareness  as  the  basis  for  deciding  what  the  future  targets  should  be  and  how  to  get  there. 

3.  Information  exchange  is  about  who  the  other  players  arc,  what  they  might  be  doing  and  what  their 
intentions  might  be. 

4.  Status  reporting  is  about  the  end-point  status  of  the  mission  field  and  players. 


14-7 


5.  Current  situational  awareness  is  about  maintaining  awareness  of  the  immediate  state  of  the  mission 
field  — locating  where  specifically  items  are.  This  information  merges  with  the  primary  situational 
awareness  to  drive  the  planning  process  (C2  mode  2)  whose  output  may  then  drive  the  information 
exchange  with  other  players  and  comes  out  with  the  status  plotting  and  reporting  of  mode  4. 

6.  Directing  plan  of  execution  is  concerned  with  when  events  are  to  happen,  cued  by  the  status  of  the 
mission  field  and  conditioned  by  the  state  of  the  available  technology. 

7.  Equipment  and  system  operation  is  concerned  with  the  hands-on  operation  in  response  to  the  directions 
from  mode  6.  This  mode  concerns  the  specific  protocols,  sequences  of  operation  and  the  dynamics  of 
control  or  perception  required  to  control  the  equipment. 

8.  System  monitoring  concerns  the  process  of  maintaining  general  awareness  of  system  performance  and 
capability,  of  what  reserves  are  left  and  of  approaching  decision  points,  danger  areas  etc.  — in  order  to 
sustain  the  intended  programme  of  action. 

9.  Alarms,  alerts  and  warnings  concern  the  feedback  of  system  status  information  which  might  change  the 
ongoing  plan  of  execution. 

10.  The  internal  co-ordination  and  communication  mode  is  about  the  internal  comms  system  for  basing 
with  other  systems  under  control,  for  re-configuring  the  system,  re-loading  new  software,  stage  changes, 
etc.  This  mode  concerns  the  command  of  how  the  system  is  configured  to  achieve  the  desired  results. 

As  the  project  progressed,  and  the  HCI  concepts  evolved,  it  became  possible  to  translate  the  skeleton 
command  and  control  structure  and  decision-making  requirements  into  the  specific  tasks,  shaped  by  the 
particular  implementations  and  applications.  In  other  words,  the  analysis  began  with  the  generic  man-centred 
task  and  then  added  the  implications  from  the  mission  context  and  the  technology  available.  This  led  to  the 
specification  of  the  system  requirement.  This  also  allowed  variations  in  scenarios  and  the  state  of  the  operator 
to  be  taken  into  account. 

The  rating  methodology 

A progression  of  assessments  was  developed  so  that  each  provided  relevant  training  or  briefing  for  the  higher- 
level  assessments  and  requirements  capture  to  follow.  These  comprise  the  Athena  HCI  Assessment  Suite  (see 
Smalley,  1998). 

There  arc  two  sides  to  rating  the  HSI  for  decisions.  These  arc  the  consequences  in  terms  of  the  importance  to 
the  task.  The  other  is  in  terms  of  the  quality  of  the  equipment  interface  provided  to  support  the  decision. 

The  Cooper-Harper  rating  method:  At  the  heart  of  the  assessment  methodology  is  a modification  of  the 
well-established  Cooper-Harper  rating  scale.  This  provides  the  thinking  tool  to  take  a particular  task  and 
assess  the  utility  of  the  equipment  offered  to  support  that  task.  The  ratings  range  on  a ten  point  scale  from 
something  like  fatal  consequences  to  certain  and  effortless  success. 

The  original  Cooper  Harper  scale,  was  developed  for  aircraft  handling  assessment  — it  was  developed  by 
George  E Cooper  of  the  Ames  Research  Center,  Moffett  Field,  California,  and  Robert  P Harper  Jr  of  Cornell 
Aeronautical  Lab  Buffalo,  New  York.  Essentially,  their  rating  method  provides  an  algorithm  for  the  operator 
to  answer  questions  about  the  function  under  assessment  until  reaching  a score,  which  is  the  assessment 
rating.  The  rating  is  obtained  through  three  dichotomous  decisions  about  the  equipment  under  test  for  the  task: 

1.  controllable/uncontrollable; 

2.  acceptable/unacceptable;  and 

3.  satisfactory  /'unsatisfactory. 

This  is  followed  by  a progressive  refinement  of  the  assessment.  At  no  point  is  the  required  discrimination 
more  complex  than  a good,  bad  or  indifferent  rating,  and  the  resulting  scores  may  be  inteipreted  according  to 
the  table  shown  in  Figure  4. 
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Score 

Acceptability 

Applicability 

1-3 

Satisfactory 

Normal  use 

4-6 

Unsatisfactory 

Emergency  use 

7-9 

Unacceptable 

No  operation 

10 

Fatal/uncontrollablc 

Figure  4.  Interpreting  the  Cooper-Harper  scores 


In  summary,  the  C-H  assessment  technique  provides  a formal  operability  rating  of  the  interface,  in  a way  that 
is  useful  to  the  development  of  the  interface  and  decision  aiding  equipment.  This  technique  does  not  measure 
how  well  the  operator  can  do,  but  produces  a rating  that  can  be  translated  into  specific  sentences  about 
whether  specific  tasks  can  be  routinely  performed  to  specific  degrees,  i.e.  it  is  a rating  of  the  interface,  using 
the  operator  as  a measure. 

These  ratings  were  useful  for  two  purposes:  to  check  the  completeness  of  the  requirement  capture,  and  to 
prioritise  where  development  effort  should  be  applied  by  producing  a "maturity  profile"  to  give  an  indication 
of  how  much  further  development  effort  might  be  required.  This  is  important  to  indicate  how  far  down  the  line 
an  acceptable  solution  may  lie. 

Maturity  of  concept  and  design:  We  discovered  that  diverse  ratings  reflected  unclear  definitions  of  the 
task’s  purpose.  Hence  the  tool  could  be  used  to  focus  attention  on  where  clarification  was  needed  from  the 
expert  users.  Once  the  task  was  clearly  defined  (as  a user  guide  for  instance)  a remarkable  consistency  of 
scoring  was  achieved.  (See  also  Harris  et  al,  1998). 

Analysing  the  rating:  Whilst  the  C-H  assessment  gives  a rating  which  relates  directly  to  the  importance  of 
improving  a function  for  operational  purposes,  it  does  not  specify  the  nature  of  the  improvement  which  might 
be  needed.  The  important  point  here  is  that  the  C-II  rating  concept  was  extended  to  capture  the  reasons  for  the 
imperfection  by  asking  for  comments  to  defend  the  rating  applied,  locating  where  the  specific  difficulties 
occurred  in  the  successive  stages  of  making  the  decision  — see  Figure  5. 


Task 

Psychophysical  issue 

1. 

Monitor  and  detect 

(signal  detection) 

2. 

Identify  and  classify 

(perception) 

3. 

Associate  and  correlate 

(interpretation) 

4. 

Connection  of  meaning  and  decision  taking 

(execution) 

5. 

Response  and  action 

(action) 

Figure  5.  Stages  in  making  a decision 


There  is  not  time  or  space  to  pursue  this  in  detail  here.  Suffice  it  to  say  that,  for  any  decision-making  function, 
the  HCI  could  be  rated  for  all  its  phases  of  operation  for  each  of  the  different  modes  of  command  and  control. 
Ratings  and  comments  could  then  be  merged  and  consolidated  requirements  could  be  obtained.  This  gave  a 
clear  indication  of  what  needed  to  be  done  to  move  the  design  towards  perfection  — or  at  least  a rating  of  1-3. 


Conclusion 

In  conclusion,  the  methodology  that  evolved  has  provided  the  basis  for  a generic  C2  requirements  capture  and 
analysis  tool,  which  has  been  refined  and  included  for  use  with  the  HCI  Guidelines  developed  at  Malvern  for 
future  military  airspace  management  systems. 
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